There is an approach called scalar replacement for optimizing the program in which variables on a global memory are replaced into local locations in a method (such as local variables). This optimization is known to have not only an effect to “reduce a cost for a memory access”, but also a secondary effect to significantly increase an effect of a subsequent optimization (such as elimination of a common subexpression), because of the extended area where the replaced variables can reside.
If the scalar replacement is executed, there is an inconvenience in a method invocation residing in the program. That is, since a value of the variable on the global memory may be changed within the invoked method, it has not been able to simply optimize beyond the method invocation.
Conventionally, there is a method for optimizing the memory access beyond the method invocation, in which a technique called Escape Analysis is used to analyze in the invoked method, and the optimization is executed based on the result of the analysis. In this method, for an object created by new, newarray or the like in the method, the optimization is executed by taking the memory of the object not in a heap area but in a stack area, only in the case where the object may not be referred to from outside of the method, in all location within the method (which is referred to as “the object does not escape”). Note that the Escape Analysis is described in detail, for example, in the following documents 1 and 2:    Document 1: Escape Analysis for Java® (In Proceedings of the 1999 ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (hereinafter referred to as OOPSLA) '99); and    Document 2: Compositional Pointer and Escape Analysis for Java® Programs (OOPSLA '99).
However, as described above, optimization using Escape Analysis is not able to perform optimization for the method in the case where there is even only a single part escaping in the method.
In addition, since analysis in an invocation method with the Escape Analysis requires a significant process cost, it may be difficult to induce. For example, when the analysis is applied to a compiler such as a JIT (Just In Time) compiler in Java®, which is affected in its compilation time, there is a very severe limit in the consideration of method size and the like.
Furthermore, the analysis in the invocation method itself may not be executed at all because of, for example, a dynamic call command.